Sealing is a one-on-one exchange between a client and each processor. No group ceremony, no shared setup, no processor ever talking to another.
The output is a package that only reconstructs under the client's chosen conditions, and only when enough independent processors cooperate.
Step 1 · Choose the shape
The client picks n processors and a threshold k.
Every qualifying group of k out of n becomes a recovery path. Within each group the client assigns a closed loop, so each processor has one successor in that group and the k members are fully self-contained at recovery time. No outside party is ever needed.
n
The pool
How many processors the seal is spread across. More paths, more availability.
k
The threshold
How many must cooperate to recover. The collusion bar any attacker has to clear.
↻
Closed loop
Inside each group, a → b → c → a. Every partial decryption a path needs is supplied from within the path.
a
b
c
c loops back to a: one self-contained recovery path
Step 2 · The core construction
Every secret is locked under a three-part composite key.
For each processor, the client builds a public key out of three pieces. Only one belongs to the processor, and it can never tell which others are in the mix. Step through it.
{{ tab.label }}
pk_iProcessor's own key
+
pk_otherSuccessor in the loop
+
pk_randomClient's fresh secret
pk_i
+
pk_other
+
pk_random
pk_comboOne opaque public key
Client
Processor iverifies its key is inside
Processor ipartial
+
Successorpartial
+
Clientlocal secret
Unlocks
{{ stepTitle }}
{{ stepBlurb }}
pk_combo = pk_i + pk_other + pk_random
{{ stepLabel }}
Step 3 · Keep it honest
A zero-knowledge proof stops the client from cheating the composite.
With each request the client proves, in zero knowledge, that the successor slot really holds another registered processor's key. The processor learns nothing about who that successor is or what the client's secret piece is. It only learns that its cooperation will genuinely be required.
What is proven
The successor is a real member of the on-chain processor registry, and the client knows the discrete log of its own random piece. Nothing else leaks.
The attack it blocks
Without it, a malicious client could slot in a key it secretly controls, quietly collapsing a k-party lock into a 2-of-2 it can open alone.
Batched once
The registry membership part is identical across a processor's lanes, so the proofs batch into one, cutting client proving time roughly by the lane count.
Step 4 · The exchange
What each processor does, in three phases.
The client sends the composite keys and proofs. The processor verifies, generates secret material, and binds it, then hands back everything the client needs. The processor never sees the payload and never talks to another processor.
Phase A
Verify
Check the client's authorisation and the membership proofs against the on-chain registry. If a proof fails, the interaction stops.
Phase B
Generate
Draw fresh random scalars, publish a commitment for each, sign each scalar's hash, and homomorphically encrypt them under the composite keys.
Phase C
Bind
Hash the whole bundle together with the seal's conditions and sign it, so the returned material is provably tied to this exact request.
The signature is the leash. Because the processor signed each scalar's hash, if that scalar ever surfaces outside a valid recovery it is permanent, on-chain proof of misbehaviour against that exact processor.
Step 5 · Lock the payload
The vault key exists for a moment, then nobody holds it.
The client picks one lane per processor and sums their hidden scalars into a vault key. No party ever holds it in the clear. That key encrypts a random value, that value encrypts the payload key, and then the client throws the vault key away. Recovery has to rebuild it from scratch through the processors.
Chosen pathone lane each
Vault keyheld by no one
Encrypts z
Payload sealed
Why the vault key is never published
If it were, an attacker could sum public commitments and pick out the right path instantly, skipping the search that makes collusion expensive.
The z indirection buys append-only
A separate public key derived from z carries no link to the path, so anyone can keep encrypting new data into the sealed store long after sealing.
The output
What the seal leaves behind.
The package is split by who is allowed to see what. The client holds the private material, a single shared copy carries the conditions and payload, and a thin public slice lets anyone watch for recovery attempts.
Client-held
Private material
The encrypted scalars, composite keys, commitments, signatures, and membership proofs. Everything a recovery needs, useless without processor cooperation.
Shared once
Conditions & payload
The unseal conditions and the encrypted payload itself. One copy covers every recovery path in the seal.
Public
Observer slice
Reveal values and condition metadata, with no private content. This is what makes every recovery attempt auditable in the datastream.
Sealing finishes with nobody holding the secret, and every party able to prove what they did.